\documentclass{IEEEtran}

\usepackage{moreverb}
\usepackage{graphicx}
\usepackage{url}

\begin{document}

\title{Packet Marking System for Enhanced Traffic Profiling 888}

\author{
\IEEEauthorblockN{Andr\'e Z\'uquete, Pedro Correia and Hassan Shamalizadeh}\\
\IEEEauthorblockA{IEETA / Univ. of Aveiro
Campus Univ. de Santiago\\
Aveiro, Portugal, 3810--193\\
Email: andre.zuquete@ua.pt}
}

\maketitle

\begin{abstract}
This paper describes a system for managing the tagging of traffic
for creating detailed personal profiles. The ultimate goal of this
separation is to facilitate the task of traffic auditing tools,
namely in their struggle against botnets. The architecture was
designed for domestic or enterprise facilities and uses the 802.1X
authentication architecture as the base support infrastructure for
dealing with unequivocal traffic binding to specific entities
(persons or servers). Simultaneously, such binding uses virtual
identities and encryption for preserving the privacy and protection
of traffic originators from network eavesdroppers other than
authorized traffic auditors. The traffic from each known originator
is profiled with some detail, namely it includes a role tag and an
application tag. Role tags are defined by originators and only
partially follow a standard policy. On the contrary, application
tags should follow a standard policy in order to reason about
abnormal scenarios raised when correlating traffic from several
instances of the same application. A first prototype was developed
for Linux, using iptables and FreeRADIUS and conveying packet tagging
information on a new IP option field.
\end{abstract}

\section{Introduction}

The Internet is growing at an unprecedented rate. With its wide
spread use amongst all kinds of people, it has become the favourite
platform for network criminals and hackers. Botnets are not a new
problem~\cite{Puri03}, but are becoming a frequent and severe
security problem~~\cite{Schiller07}. The risks raised by bots
inumerous, both for the hosts where they get installed, where they
are able to do all sort of illegal actions, but also for
organizations attacked by botnets, which are unable to find and
persecute the actual attackers screened by the botnet.

\subsection{Motivation}

No matter the malicious goal of a bot, it needs to interact with
some managing entity, both for getting instructions and for
providing information. This has a direct consequence on the
organization were the bot was installed: it generates abnormal
traffic. Nevertheless, in most cases it may be difficult to clearly
identify that traffic as abnormal, because for doing that we need
first some notion about what normal traffic is. However, the traffic
is changing all the time, mostly because new applications (or
plugins/add-ons) are frequently being installed in computers or old
applications are patched/upgraded. Therefore, to have a clear notion
of what is normal or abnormal, we need to detect traffic variations
on particular applications, or caused by new applications.

\subsection{Problem}

A network auditing tool (e.g. the network intrusion prevention and
detection system Snort\footnote{\url{http://www.snort.org}}) has
limited capacities for building profiles of normal traffic, in order
to be able to clearly identify abnormal traffic immediately when it
appears. In particular, it cannot extract from the inspected traffic
some fundamental information that can help to build detailed,
personal profiles. Such profiles are critical for implementing a
divide-to-conquer strategy. The fundamental information that we are
talking about is traffic authorship. i.e., which user, operating
system and application is in fact producing the traffic.  

Without this notion of authorship, it becomes very hard to build
trustworthy traffic profiles. In fact, IP addresses are not a good
source for extracting user authorship, as a person may be using
several machines and may get different IP addresses each time it
establishes a network session. Therefore, we need to be able to
extract from packets a stronger notion of user authorship other than
the source IP address.

Furthermore, packets only refer the originating host, not the
originating application. Transport ports are not helpful, as they
can be used by any application. Once again, this information can be
vital to build profiles, since a particular traffic may be normal
when generated by one application but unusual when generated by
another one. Therefore, we need to be able to extract from packets
some information about the originating application, in order to
improve the accuracy of profiles. With this information, we are able
to build per-application profiles instead of profiles per operation
system.

\subsection{Contribution}

The goal of this paper was to design and implement a solution for
facilitating the traffic separation in many different profiles, in
order to facilitate its analysis by auditing tools, such as Snort.
The ultimate goal of such analysis is to find evidences of the
presence of bots.  

For facilitating such separation, we designed an architecture for
managing virtual identities and for tagging traffic subject to
inspection with extra information useful for traffic separation and
analysis. The extra information is composed by a virtual
identification of the user using the originating host and identity
of the originating application. This extra information can help
(authorized) network auditing tools to build accurate personal
profiles, which we believe could help a great deal on the detection
of abnormal traffic and, consequently, on the detection of bots.

Virtual identities are identifiers composed by two types of
attributes: entity pseudonym and role. The entity pseudonym is an
semantic-free identifier of a person or network server (host) that can be
linked to that person or server by specific authentication
services. The role is the reason behind the generation of the
traffic. For persons, the roles may be ordinary user, network
administrator, security inspector, etc. User roles may be further
detailed to encompass business roles. Roles are also used to
separate traffic originated by operating systems from the traffic
created by users' applications.

These virtual identities allow auditing systems to improve their
accuracy, by providing the means to build more focused network
profiles of traffic originators. By using virtual identities,
auditors can become insensible to normal network activities that
introduce confusion in the mapping of traffic to specific
originators. Examples of such activities are dynamic allocation of
IP addresses and IP translations performed by NAT boxes.

In this paper, we also studied the feasibility of a real-time
traffic tagging and auditing system, that tags each packet of
traffic at the originating machine running the profile stamping
application. IP packets at present only allow differentiation with
protocol-specific identifiers (source and destination
addresses/ports, protocol number, etc.). Our differentiation
mechanisms allows us to inspect and identify the packets based on
the application that generated them, the originating entity and the
role it was running.

Additionally, our system provides authentication mechanisms to assist
auditors of the tagged traffic to verify the authenticity of the
carried tags. This protection is fundamental for preventing profile
poisoning attacks, i.e., attacks with fabricated or spoofed tags
with the goal of disturbing existing profiles.

Finally, our differentiation tags can also help creating improved
application-specific traffic profiles. Accurate application
inference is a prerequisite for many network management tasks, such
as QoS, accounting and anomaly detection, etc. Service providers
commonly infer application classes by means of traffic flow
measurements provided by routers
\cite{Jin:2010:IAN:1811099.1811082}. With our system, we do not need
to resort to such inference.

\section{Architecture}

As previously stated, our contribution is a system that allows a
more refined identification of the origin of packets. Namely, we
want to clearly identify the entity (person or server) that sent the
packet, the application responsible for its fabrication and the role
played by the entity that launched the application, which should
justify the network activity. For reaching this goal, we need
decided to add authenticated tags to outbound packets, and to enable
authorized auditing applications to interpret those tags in order to
build profiles and detect anomalies.

In this section we describe the architecture of our packet tagging
system. The system encompasses several components, namely: a
pseudonym manager, a client tagging application and a packet validation
helper.

\subsection{Overview}

\begin{figure}[!h]
\centering
\includegraphics[width=2.5in]{Arq}
\caption{Proposed architecture}
\label{arch.Fig}
\end{figure}

Figure~\ref{arch.Fig} shows the components of our packet tagging system, as
well as some interactions among them.

At some initial stage, possibly when a computer joins the network,
its owner (or user) initiates a session with a Pseudonym Manager (PM). 
The goal of this session is to obtain a pseudonym for a network
session. For network session we mean period of time where the
computer will generate traffic on behalf of its owner/user. 
Different sessions should yield different pseudonyms, otherwise it
could become trivial to identify each and every person/service.

Each pseudonym is provided together with a session key. The session
key will be used to prove the honesty of packet tags added by the
pseudonym holder. In other words, it will be used to prove the
origin authentication of the packet tags. Session keys are at start
shared only by the PM and the computer that holds the related
pseudonym. This allows the PM to act as a validator of packet tags
for untrusted third parties. For untrusted third parties we mean
network elements/equipments that may be authorized to perform
traffic analysis tasks while not being trusted enough for getting
access to session keys. For trusted third parties, the PM may convey
a session key, in order to offload that costs of tag validation to
other hosts.

Hosts connected to the network may run voluntarily a packet tagging
tool. It should be stressed that enforcing the execution of this
tool is mainly a decision from the network administration. This
means that a network administrator can impose this tool on some
machines and not on other machines. The network administrator can
also impose that traffic flowing on a particular link/direction must
be tagged, while all the other may remain unchanged.

The Client Tagging Application (CTA) adds a set of tags to each outbound packet;
inbound traffic is not affected or analysed. The packet tags include:
\begin{itemize}
\item The host pseudonym;
\item The identification of the originating application;
\item The identification of the application's role (or, in other
      words, the role of the user exploring the application).
\end{itemize}

The pseudonym can be used to aggregate traffic belonging to a
particular entity (person or server), therefore it facilitates the
task of building personal profiles. The identification of the
originating application can be used to aggregate traffic belonging
to the same application, in the same operating system or not,
therefore it facilitates the task of building application's
profiles. Finally, the role identification can be used to aggregate
normal interactions within each role of each person/server,
therefore it facilitates the subdivision of personal profiles in
smaller profiles, where anomalies are likely to be detected more easily.

The Packet Validation Helper (PVH) is a library that helps network
auditing tools to validate tagged packets. The functionality of this
helper is to enable auditing tools to fetch all elements that may
be required to properly conduct its activities, namely:
\begin{itemize}
\item Identification elements of the entity using a particular
      pseudonym (revocable anonymity);
\item Identification elements of the application referred in the
      packet (e.g. common name, version, etc.);
\item Validation of packets' tags added by a particular pseudonym;
\item Fetching the session key of a particular pseudonym.
\end{itemize}

\subsection{Pseudonym Manager (PM)}
\label{PM}

As previously referred, the PM is the component that keeps bindings
between people or servers and pseudonyms. The later are
semantic-free numbers, that can only be resolved to identities of
people/servers by the Pseudonym Manager. Furthermore, the PM keeps a
link between pseudonyms and session keys. Finally, auditing
applications, using the packet validation helper, interact with the
PM to validate packets' tags or to fetch session keys.

Considering all these requirements, the most natural way to deploy a
service like the PM is by integrating it with a AAA (Authentication,
Authorization and Accounting) service, such as RADIUS~\cite{}. AAA
services provide the means to authenticate users (and, indirectly,
the hosts they are using), provide the means to authenticate
applications (or the hosts where they run) and are usually extensible.

We designed our PM to be integrated with a AAA server (RADIUS)
within a 802.1X authentication framework. 802.1X is a scalable,
port-based network access control architecture, suitable for
authenticating the entities running hosts wishing to attach to a LAN
or WLAN.

\begin{figure}
\centering
%\includegraphics[width=2.5in]{802}
\caption{802.1X phases on a WLAN, negotiated keys and derived keys}
\label{802.Fig}
\end{figure}

In the 802.1X jargon, a host wishing to attach to a network is
called a supplicant. During the attach process, the supplicant and a
central Authentication Server (AS), typically a RADIUS server,
authenticate each other using an authentication protocol
encapsulated in EAP (Extensible Authentication Protocol~\cite{rfc3748}). 
One of the outcomes of the authentication protocol is a secret key,
EMSK (Extended Master Session Key), shared only by the supplicant
and the AS (see Fig.~\ref{802.Fig}).

Our PM was designed as an extension of a AS and using a key derived
from EMSK. Such key derivation follows the rules stated
in~\cite{rfc5295}, which explains how Usage-Specific Root Keys
(USRK) are derived from EMSK. For our tagging system, we used the
rules of this standard for computing several values, namely
pseudonyms and keys (hereafter referred as tagging keys):
\[
\mbox{OP} = \mbox{KDF} \left( \mbox{EAP Session-ID}, \mbox{``Tagging system''}, \mbox{EMSK} \right)
\]
\[
\mbox{MTK} = \mbox{KDF} \left( \mbox{EMSK}, \mbox{``Master tagging key''} \right)
\]
\[
\mbox{TSK} = \mbox{KDF} \left( \mbox{MTK}, \mbox{``Tagging secrecy key''} \right)
\]
\[
\mbox{TIK} = \mbox{KDF} \left( \mbox{MTK}, \mbox{``Tagging integrity key''} \right)
\]
\noindent
where OP means Origin Pseudonym, MTK means Master Tagging Key, TSK
means Tagging Secrecy Key, TIK means Tagging Integrity Key and KDF means key derivation function. 
According to~\cite{rfc5295}, OP is a \textit{USRKName}, i.e., a name for
referring a USRK (in our case, MTK). MTK is our session key, linked
with OP; it is a USRK, since it is the root key for our tagging
system for each session. The TSK is a key that will be used to
provide secrecy to tags, in order to prevent unauthorized
eavesdroppers from collecting useful information from them.
Finally, TIK is a key that will be used to authenticate tags,
allowing authorized auditors to assert their integrity. The keys derivation is presented at figure \ref{key_deriv}.

\begin{figure}[!h]
\centering
\includegraphics[width=2.5in]{App_Keys}
\caption{Key Derivation Model}
\label{key_deriv}
\end{figure}

The supplicant does the same computations than the PM, reaching the
same values for OP and MTK. Thereafter, it will only use OP for
tagging outbound traffic and MTK for computing RTKs, which will be
used to prove authenticate the origin of traffic tags.

The PM keeps a permanent store with mappings between an OP and the
related MTK (see Fig.~\ref{}). It also maintains a mapping between a
OP and a descriptor of the entity (person or server). This last
mapping is crucial for building entity-related profiles from tagged
traffic. Furthermore, for each descriptor the PM must keep a
persistent, unique number for allowing auditing tools to aggregate
traffic originated by different OPs without bothering with the
details of their real-world identification.

\subsection{Client Tagging Application (CTA)}

The CTA is a component that theoretically stays between the host and
the network. It is responsible for tagging all outbound traffic with
the correct values expected by auditing tools. Note that it does not
know if such tools exist; they are transparent for the CTA. 
Therefore, the CTA simply assumes that they may exist, and as such
does its job all the time.

For tagging traffic, the CTA must know the current OP and its MTK. 
This data is provided by the application that manages the 802.1X
supplicant after creating each EAP session. Furthermore, the CTA
needs to know the originating application and the role played by the
entity that launched it.

\subsubsection{Role management and inference}
\label{sec:c_1}

The management of roles is not straightforward, as it raises a new
requirement for users that they are not used to. We decided to use
the following policy for simplifying the role management workload on
Linux hosts with or without graphical interface:

\begin{itemize}
\item Any application with standard I/O devices capable of
interacting visually with the user (consoles, X terminals) is
considered a user application.
\item Any application belonging to the process group of a user
application is also a user application. This is useful for including
applications used in shell pipelines as user applications.
\item Applications other than user applications are considered
operating system applications, with the \textbf{operating system role}.
\item User applications running with root effective UID (0) and
without a different real UID are considered to be on a
\textbf{self-administration role}. Applications running with elevated
privileges due to set-UID mechanisms are not included in this role.
\item Other user applications have a role that is given by the
virtual desktop where they have the user interface.
\end{itemize}

This policy for obtaining the role of an application makes it easier
for users to manage roles. In fact, the only work they have is to:
\begin{itemize}
\item Create a set of virtual desktops equal to the number of roles
      they play.
\item Give to each virtual desktop a different, arbitrary role name.
\item Run on each virtual desktop only the applications
      needed for its role.
\end{itemize}

The user (entity) has the ability to create as many virtual desktops
as he wants in order to clarify the roles he plays. Furthermore,
role names are arbitrarily chose by users, there is not a universal
policy for choosing names.

Note that users only gain by collaborating with the tagging system,
as it allows auditing tools to detect malicious code running on
their machines, namely bots. Therefore, users should maintain a
stable set of names for their roles, otherwise they introduce
entropy in role-based profiles.

\subsubsection{Packet tagging}

For adding our tags to packets we add to chose a standard way, in
order to enable tagged packets to be accepted by all systems.
Consequently, we decided to encapsulate tags within a single IP option.

The new IP option will contain the following fields:
\begin{itemize}
\item{\bf OP}. This is a 14 byte value, computed as described in Section~\ref{PM}.
\item{\bf Role}. This is a 8 byte value. Its two high
      order bits have this values:
      \begin{itemize}
      \item{00}: operating system (OS) role;
      \item{01}: self-administration role;
      \item{10}: user-defined roles;
      \item{11}: reserved for future extensions.
      \end{itemize}
      The other 62 bits are filled with the high-order bits of an
      hash of:
      \begin{itemize}
      \item the operating system identity (e.g. as given by the
            Linux ``\texttt{uname -sr command}''), for the OS role
	    and for the self-administration role;  or
      \item the user-provided role name, extracted from the virtual
            desktop of the application.
      \end{itemize}
\item{\bf Application}. This is a 8 byte value, filled with the
      high-order bits of an hash of the textual identification of
      the application (e.g. ``Firefox 5.0'').
\item{\bf Authenticator}. This is a 16 byte value, computed by
      encrypting, with TIK, an hash of the previously referred
      tags, together with some parts of the IP packet.
\end{itemize}

For privacy sake, the role and application fields are encrypted
together with TSK, in order to hide information about
operating systems and applications used by the originator of the
packet. This way, we prevent this useful information to be reveled
to others than the authorized network auditing applications.

The computation of the authenticator poses some concerns. On one
hand, we would like to bind and authenticator to the hole packet
contents, in order to prevent authenticators from being easily
copied to other packets. On the other hand, we need to take car with
existing network equipment that may change the packet contents
transparently for its originator (routers, NAT boxes, etc.). We
decided the use the following original packet data for computing the
authenticator:
\begin{itemize}
\item Destination IP address.
\item Modified IP payload. The modification consists in the zeroing
of all fields that are likely to be modified by network elements,
namely NAT boxes, such as transport source ports (UDP or TCP ports),
GRE keys~\cite{rfc2784}, etc.
\end{itemize}

The total length of an IP option is two bytes more than its optional
data. This means that that, in our case, the total length of the
tagging option is $2+14+8+8+16 = 48$ bytes (see
Fig.~\ref{layout.Fig}). This value is intentionally a multiple of 4
bytes, because this IP headers must have a length multiple of 32-bit
words. The size of the role and application tag, all together, is a
multiple of 8 bytes, which is advised because most symmetric
encryption algorithms support data lengths of 64 bits.

\begin{figure}
{\scriptsize
\begin{boxedverbatim}
+------------+------------+------------+------------+
| Op. type   | Op. length | Origin Pseudonym (OP,   |
+------------+------------+                         +
| 16 bytes)                                         |
+                                                   +
|                                                   |
+                                                   +
|                                                   |
+------------+------------+------------+------------+
| Role tag (8 bytes, encrypted with TSK)            |
+                                                   +
|                                                   |
+------------+------------+------------+------------+
| Application tag (8 bytes, encrypted with TSK)     |
+                                                   +
|                                                   |
+------------+------------+------------+------------+
| Authenticator (16 bytes, encrypted with TIK)      |
+                                                   +
|                                                   |
+                                                   +
|                                                   |
+                                                   +
|                                                   |
+------------+------------+------------+------------+
\end{boxedverbatim}
}
\caption{Layout of the IP option used to convey our profiling tags
and related information (OP and authenticator).}
\label{layout.Fig}
\end{figure}

\subsection{Packet Validation Helper (PVH)}

This component is to be used by authorized auditing tools that need
to interpret the IP options field previously described. For doing
so, the PVH provides the following functionalities.

First, it allows authorized tools to establish a secure
(authenticated) session with an AS (e.g. a RADIUS server). For this
goal, it uses the same methods that are normally used by RADIUS
clients (Network Access Devices, Network Access Servers, etc.):
request/response authentication by means of a secret key, shared with the AS.

Second, the PVH enables an authorized auditor to fetch the key MTK
of a given OP from the AS. The purpose of this functionality is to
enable the auditor to perform packet validations and inspections
using only local resources, i.e. without requiring further help of
the AS for that OP.

Third, the PVH enables an authorized auditor to get the decrypted
values of the role and application tags given an OP.

Finally, the PVH enables anyone to validate a packet. This is useful
for implementing network filters that drop invalid packets. The
validations if performed both by the auditor and the AS. First, the
auditor sends the OP and the encrypted authenticator to the AS,
which decrypts the later and returns the result. Then the
authenticator computes the expected authenticator from the packet
and compares it with the value received from the AS. If there is a
mismatch, then the authenticator is not valid and the packet may be
eligible for dropping.

Given these functionalities, it is worth noting that the
authenticator should be computed over the encrypted values of the
role and application tags, instead of their original values.
Otherwise, it would be impossible to validate packets without
decrypting these values, which would only create a useless
computational overhead without any relevant security gain.

\section{Implementation} 

Application is developed in Python and at this time is to be running
on any machine with a Linux system with Python interpreter and Gnome
with Metacity support (commonly used) - a window manager that
provides necessary libraries such as \emph{libwnck} to separate the
role based activities \cite{Libwnck:website}.  In this work the important part is to find a method to subdivide the roles as described in the architecture \ref{sec:c_1}.
Is implicit that a role would be an activity performed by a user in a
particular workspace of the gnome desktop manager or otherwise an activity embedded in operating system.

\subsection{Application per Role Service}
This part of Client Tagging Application describes the functionality
available for getting the names of applications running at some time
period. At this work was implicit that one role corresponds to one
workspace, besides the roles from operating system and from self-administration. The names of workspaces can be configured in runtime using Metacity GUI for desktop management and as an example the workspace 1 from gnome window manager can be called "Fun", Workspace 2 "Work", workspace 3 "Leisure" and so on without any limitations on the number of roles that a user can/want to have.  After this division of roles is necessary to know which
applications are running in each workspace so has used the libwnck library that allows us to iterate over each workspace and find the
PID of each application that is running.  These applications
necessarily need to have a real window in the desktop, that is an
object of type WnckWindow because the identification is made through
this for later access PID and Workspace where WnckWindow is
present.
This function is executed each time there is a signal for closing or
opening a window and stores a list of applications PID and workspace
in a Python dictionary that is no more than a hash table. 
All other applications that do not have a match with a window on a desktop will belong to the group of applications the operating system or so-called self-administration role.
To differentiate these two types mentioned above was created a mechanism to obtain information about the effective UID and real UID from different processes, so this module collects from /proc linux directories all UID either effective or real and matches them following a criteria: if a efective UID with value 0 then we see real UID and if it is the same, the role parameter will be set as self-administration and so if this UID is different we try to find a open window in desktop to see if it is a user application, if there is no window we set the role as operating system.
After obtaining the information of the roles played by each PID is stored in a Python dictionary a set of pairs PID: Role Played.

\subsection{Socket-Application Matching Service}
This part of the application can iterate over /proc linux system and
create a Python dictionary with the association between ports and
PID responsible for them. It is a netstat kind of service for native
Unix systems. This dictionary is updated every time there is a port
of a package going out of the machine that do not belong to the
dictionary. At this moment is possible to have an interconnection
between this service and the one presented before so at runtime
there is the possibility to have a 3-tuple of PID, Role, Socket to
classify the TCP and UDP packets in the outgoing queue from the machine.

\subsection{Marking Packet Service}
In another part of the packet tagging process was necessary to
establish which fields would be established as a type for  the tag
to use and what would be the general tag in the
packet.
Since on an IP packet the only possible change to modify the
packages would be insert changes in the IP options field that was
the solution adopted instead of adding more data to be transferred
with each packet, or either case carry packets with independent tags
at the beginning and the end of a communication signalling that an
instance of an application in a determined workspace was started.
It was adopted a powerful interactive packet manipulation program who is able to forge or decode packets of a wide number of protocols, send them on the wire, capture them, match requests and replies, and much more.
In the first part of this task the client application waits for the
receipt of MTK - Master tagging key that is assigned after the
RADIUS server authentication carried out via the wpa-supplicant
module. This can occur because the client blocks all outgoing
packets from the machine in userspace zone using iptables and
NFQUEUE, after wpa-supplicant sends the key to a predefined port
that application know that will only be used receiving MTK. 
From MTK is possible to calculate the secondary keys necessary for
the process, namely TSK and TIK.
The secondary keys involves the application of
pseudorandom function family (PRF +) described in IKEv2 RFC as shown in Architechture - B Pseudonym Manager.\newline
After this is chosen to the IP Options field the first 8 Bytes of Role Tag encrypted with TSK, the first 8 Bytes of Application Tag encrypted with TSK also, and 16 Bytes of Authenticator encrypted with TIK. All size of this fields is considered to not be larger than the size of IP Options model.
At figure \ref{ip_options} is presented the model of an IP packet and the IP options used to tagging the packets.
\begin{figure}[!h]
\centering
\includegraphics[width=2.5in]{IpOptions}
\caption{IP Packet with IP Options model}
\label{ip_options}
\end{figure}
The tag presented in IP options will be composed by:
\begin{itemize}
\item OP - Origin Pseudonym + Options Header (16 Bytes)
\item Role Tag (8 Bytes)
\item App Tag (8 Bytes)
\item Authenticator - Encription of some parts of IP Packet with TIK - Tagging Integrity Key (16 Bytes)
\end{itemize}
With the use of Scapy library Python can handle all the received
packets in userspace zone through NFQUEUE and will be with this library that the
changes will be made to the field IP Options, particularly in the fields mentioned in the architecture. Everything will be done in real time, what the future could lead to some problems of efficiency as the amount of volume data produced by the machine where the client application is running.
\cite{Scapy:website,citeulike:2354513}.  At the second part of this
task the application checks all source ports of TCP and UDP packets
that will be compared to the socket-application matching service.
The return of this service will be an application name and role
associated to an open socket, that will be send on the fly through network. A picture of how the modules interact in the client application is shown in the figure \ref{flow_app} where the numbers correspond to the stages of communication since the arrival of a packet to exit the same machine
\begin{figure}[!h]
\centering
\includegraphics[width=2.5in]{flow_client_app}
\caption{Flow of Client Application}
\label{flow_app}
\end{figure}

\section{Radius Authentication Service}

\subsection{Radius Client Key Exchange Service}

\subsection{Radius Interface for Network Auditors}

\section{Conclusion}
With this application we attempt to provide an effective method to split the traffic generated by a utlize in order to improve the detection of anomalous traffic through the network inspectors.

\section*{Acknowledgment}

The authors would like to thank...

\bibliographystyle{IEEEtrans}
\bibliography{main,rfc-index}

\end{document}
